Cyber-physical System Development Environment for Energy Applications

Cyber-physical systems (CPS) are smart systems that include engineered interacting networks of physical and computational components. The tight integration of a wide range of heterogeneous components enables new functionality and quality of life improvements in critical infrastructures such as smart cities, intelligent buildings, and smart energy systems. One approach to study CPS uses both simulations and hardware-in-theloop (HIL) to test the physical dynamics of hardware in a controlled environment. However, because CPS experiment design may involve domain experts from multiple disciplines who use different simulation tool suites, it can be a challenge to integrate the heterogeneous simulation languages and hardware interfaces into a single experiment. The National Institute of Standards and Technology (NIST) is working on the development of a universal CPS environment for federation (UCEF) that can be used to design and run experiments that incorporate heterogeneous physical and computational resources over a wide geographic area. This development environment uses the High Level Architecture (HLA), which the Department of Defense has advocated for co-simulation in the field of distributed simulations, to enable communication between hardware and different simulation languages such as Simulink and LabVIEW. This paper provides an overview of UCEF and motivates how the environment could be used to develop energy experiments using an illustrative example of an emulated heat pump system. Introduction A cyber-physical system (CPS) consists of a set of interacting cyber-physical devices where each device contains some cyber computation that can sense events from and actuate changes on a physical infrastructure. Examples of CPS include smart cities, intelligent buildings, and the smart grid. One method to validate a CPS design uses hardware-in-the-loop (HIL) in conjunction with simulations to test the runtime dynamics of a cyberphysical device in a virtual test environment. A challenge of experiments that incorporate both HIL and simulations is that they often require a testbed that integrates hardware components with multiple, heterogeneous simulation environments. A large number of HIL testbeds which offer unique experimental opportunities cannot be replicated due to limitations in both hardware cost and development time [1–5]. These testbeds often have different architectures and utilize different simulation languages because of their independent development histories, and an experiment tailored for one testbed might not be compatOfficial contribution of the National Institute of Standards and Technology; not subject to copyright in the United States. Certain commercial products are identified in order to adequately specify the procedure; this does not imply endorsement or recommendation by NIST, nor does it imply that such products are necessarily the best available for the purpose. 1 ible with another architecture. The inability to exploit the full range of available resources in the CPS landscape leads to segregated groups of researchers who are experts in a single testbed environment but face challenges in the adoption of external research advances. In addition, integrated experiments for CPS require access to resources pooled from multiple domains to produce faithful models of the deployed system. For example, experiments on smart cities may involve collaboration across domains such as transportation, energy, and emergency response. An experiment should integrate models developed in those domains, which may involve domain-specific tools (e.g. a traffic simulator written in C++), to achieve the most realistic result. NIST envisions a universal CPS environment for federation (UCEF) which enables experiments to exploit multiple testbed architectures using a common interface. The United States Department of Defense mandated a common integration platform in the field of distributed simulators called the High Level Architecture (HLA) [6]. This paper demonstrates the use of HLA in the design and implementation of cyber-physical devices using an integration architecture that supports collaboration between physical hardware and simulations. The approach is highlighted using an example CPS implementation of an HVAC system controlled by a thermostat with a remote temperature sensor, which is a straightforward and well understood application that does not require deep domain expertise to comprehend. The rest of the paper is organized as follows. Section II provides an overview of HLA and the design process to implement an HLA federation. Section III demonstrates this design process in an example CPS through implementation of a distributed HVAC system. Section IV outlines other work on the integration of HLA with hardware, and the paper concludes with Section V. High Level Architecture HLA is an IEEE standard for distributed simulation in which individual simulations called federates join together to form a cooperative federation [6]. All federates in a federation interact using a Run-Time Infrastructure (RTI) software implementation of a set of HLA services such as publish-subscribe messaging, logical time management, and distributed object management. Data exchanges between the federates must adhere to a federation object model (FOM) which defines the set of messages understood by the federation. Although the original intent of HLA was to allow federated co-simulation of simulation platforms such as MATLAB and Modelica, a CPS federate could represent a cyberphysical device. This section provides a brief overview of this paper’s approach to designing an HLA federation with hardwarein-the-loop. The overview is based on a model-based simulation integration environment developed and maintained by Vanderbilt University called the Command and Control Wind Tunnel (C2WT) [7], but has been sufficiently generalized to be applicable to alternative HLA development environments. Federation Stack Architecture HLA does not mandate a specific RTI implementation, which can consist of two different types of components. A Local RTI Component (LRC) provides an Application Program Interface (API) to interface federates with the RTI, and a Central RTI Component (CRC) coordinates the other run-time components. A specific RTI implementation may provide a centralized CRC, multiple hierarchical CRCs, or no CRC. The results in this paper use an open-source RTI implementation called Portico which implements the LRC at each federate and requires no CRC [8]. Fig. 1 shows a federation stack architecture for this implementation that illustrates the necessary components for a federate. This figure contains three example federate types: a simulation, a cyber-physical device, and a federation manager that drives an experiment. FIGURE 1. Federation Stack Architecture Each federate has a Local RTI Component implementation which enables it to communicate with the federation, and all federates must use the same LRC implementation to ensure coherent communication between the federation members. The Portico LRC implementation uses either TCP/IP or UDP/IP sockets for its intra-federation communication. On top of this communication infrastructure, an HLA Interface exposes the set of standardized services available for federates. For the C2WT integration environment, the HLA interface is a Java abstract class which exposes the various HLA services as Java functions. The implementation of the LRC and its HLA interface are uniform across all of the federate types. For simulation platforms such as MATLAB, the federate must also contain a Simulation Engine that runs the simulation models. The simulation engine may not have a native RTI interface. In order to make these platforms compatible with HLA, an adapter labeled the Simulation Integration Wrapper must be